home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-01 / 80x0393.zip / CMDLINE.TXT < prev    next >
Text File  |  1993-03-30  |  5KB  |  120 lines
  1. By: Dave M. Walker
  2. Subj: Command Line Parms
  3. ____________________________________________________________________________
  4.  
  5. Let's see... we'll start with a listing of the parameters for @PARAM
  6. from TRSDOS 6.x:
  7.  
  8.   Parses an optional parameter string.  Its primary function is to parse
  9.   command parameters contained in a command line starting with a
  10.   parentheses.  The acceptable parameter format is:
  11.     PARM=X'nnnn' ... hexadecimal entry
  12.     PARM=nnnnn   ... decimal entry
  13.     PARM="string"... alphanumeric entry
  14.     PARM=flag    ... ON, OFF, Y, N, YES, or NO
  15.       Note: Entering a parameter with no equal sign or value is the same
  16.       as using PARM=ON.  Entering PARM= with no value is the same as
  17.       using PARM=OFF.
  18.  
  19.   Entry Conditions:
  20.     A  = 17 [SVC number, akin to function in AH]
  21.     DE = Pointer to beginning of your parameter table
  22.     HL = Pointer to command line to parse [unnecessary for the PC]
  23.  
  24.   Exit Conditions:
  25.     Success always.
  26.       If Z is set, either valid parameters or no parameters were found.
  27.       If NZ is set, a bad parameter was found.
  28.  
  29.   General:
  30.     NZ is not returned if parameter types other than those specified are
  31.     entered.  The application must check the validity of the response
  32.     byte.
  33.  
  34.   The valid parameters are contained in a user table which must be in
  35.   one of the following formats.  (Parameter names must consist of
  36.   alphanumeric characters, the first of which is a letter.)
  37.  
  38.   For use with TRSDOS Version 6 [Model IV], use this format:
  39.  
  40.     The parameter table starts with a single byte X'80'.  Each parameter
  41.     is stored in a variable length field as described below.
  42.  
  43.     1) Type Byte (Type and length byte)
  44.        Bit 7 - If set, accept numeric value
  45.        Bit 6 - If set, accept flag parameter
  46.        Bit 5 - If set, accept "string" value
  47.        Bit 4 - If set, accept first character of name as abbreviation
  48.        Bits 3-0 - Length of parameter name
  49.  
  50.     2) Actual parameter name
  51.  
  52.     3) Response byte (Type and length found)
  53.        Bit 7 - Numeric value found
  54.        Bit 6 - Flag parameter found
  55.        Bit 5 - String parameter found
  56.        Bits 4-0 - Length of parameter entered.  If length is 0 and the
  57.            2-byte vector points to a quotation mark (X'22'), then the
  58.            parameter was a null string.  Otherwise, a length of 0
  59.            indicates that the parameter was longer than 31 characters.
  60.  
  61.     4) 2-byte address vector to receive the parsed parameter values.
  62.  
  63.     The 2-byte memory area pointed to by the address field of your table
  64.     receives the value of PARM if PARM is non-string.  If a string is
  65.     entered, the 2-byte memory area receives the address of the first
  66.     byte of "string".  The entries ON, YES, and Y return a value of
  67.     X'FFFF'; OFF NO, and N return X'0000'.  If a paraemter name is
  68.     specified on the command line and is followed by an equal sign and
  69.     no value, then X'0000' or NO is returned.  If a parameter name is
  70.     used on the command line without the equal sign, then a value of
  71.     X'FFFF' or ON is assumed.  For any allowed parameter that is
  72.     unchanged and the response byte is 0.
  73.  
  74.     The parameter table is terminated with a single byte X'00'.
  75.  
  76. The other parameter format that was alluded to was used in LDOS for the
  77. TRS-80 I/III.  Briefly, this format was:
  78.  
  79.   - A 6-character parameter name, left-justified, padded with blanks.
  80.   - An address to store the parsed values
  81.     [repeat for all parms]
  82.   - A null to terminate the table
  83.  
  84. So the table would look like this using PC-eze:
  85.  
  86. VidType dw    -1                  ;Parameters & default values
  87. PortNum dw    1
  88.         db    'VIDEO '            ;Parameter name
  89.         dw    OFFSET VidType      ;Address to store response
  90.         db    'PORT  '            ;Another...
  91.         dw    OFFSET PortNumber
  92.         db    0                   ;Terminating null
  93.  
  94. No distinction was made between paramater types.  The programmer was
  95. left to figure that one out.
  96.  
  97. The first method described is a little more complicated, but easier on
  98. the applications programmer.  (That's the point to all this, right?)
  99.  
  100. This idea probably won't catch on... (I can see the error message now:
  101. "This program requires TOADPARM because Microsoft can't design a decent
  102. Operating System.") ... but it would be an EXCELLENT idea for Rex Conn
  103. to implement in the next version of 4DOS.
  104.  
  105. I suppose the two things that really bug me the most about MS-DOS are:
  106.  
  107. 1.  Lack of a task scheduler for the NMI (IRQ 8).  LDOS had system
  108.     routines that kept track of the system timer and issued vectors upon
  109.     request.  No need to save registers or fool with resetting the
  110.     hardware timer... just call the system with the address of your
  111.     routine and it's done.  It even had 2 priority levels, fast and
  112.     slow.
  113.  
  114. 2.  Lack of chained device support.  LDOS would allow you to chain your
  115.     driver, filter, hotkey, or whatever via system calls.  No need to
  116.     mess around with grabbing interrupts and such.
  117.  
  118. Ah well, maybe IBM has developed a better interface with OS/2.  Somehow
  119. I don't really think so, though.  *sigh*
  120.